home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000053_owner-urn-ietf _Thu Oct 17 13:37:45 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  7KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA06653 for urn-ietf-out; Thu, 17 Oct 1996 13:37:45 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA06648 for <urn-ietf@services.bunyip.com>; Thu, 17 Oct 1996 13:37:42 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA26944  (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 13:37:39 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14785(3)>; Thu, 17 Oct 1996 10:37:29 PDT
  6. Received: by golden.parc.xerox.com id <2770>; Thu, 17 Oct 1996 10:37:07 PDT
  7. To: rdaniel@acl.lanl.gov
  8. Cc: liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com
  9. In-Reply-To: <2.2.32.19961017163113.006ff770@acl.lanl.gov> (message from Ron
  10.     Daniel on Thu, 17 Oct 1996 09:31:13 PDT)
  11. Subject: Re: [URN] a possible security architecture for URNs
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct17.103707pdt."2770"@golden.parc.xerox.com>
  14. Date: Thu, 17 Oct 1996 10:37:07 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. >         We shouldn't define an all-encompassing
  21. >         security policy for URNs.
  22.  
  23. I agree with that. However, I had interpreted some messages (not from
  24. you, but from Michael and Terry) a different position, e.g., that the
  25. URN working group shouldn't worry about security.
  26.  
  27. > As far as the NAPTR proposal goes, those tools come from DNSSEC.
  28.  
  29. My primary technical concern about using DNS security for NAPTR is
  30. the issue of the granularity of authority. For example, it's likely
  31. that any authority with the ability to change ONE of the NAPTR entries
  32. for 'duns.urn.net' will have the ability to change all of the rest of
  33. the records.
  34.  
  35. Is this the right granularity of authority? Let's suppose that
  36. 'duns.urn.net' has replicated resolution services around the world,
  37. one in the US, one in Japan, one in Australia, one in Russia:
  38.  
  39. duns.urn.net
  40. ;;      order pref flags service            replacement                regexp
  41.  IN NAPTR 100  10  "s"  "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com ""
  42.  IN NAPTR 100  20  "s"  "rcds+N2C"         _rcds._udp.duns.com.au    ""
  43.  IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp    ""
  44.  IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru    ""
  45.  
  46. but that the Russian operator needs to change the domain name. Or
  47. wants to.
  48.  
  49. Or that the Australian operator of the resolution service disputes the
  50. Japanese operator over the spelling of a DUNS name that is in tradmark
  51. dispute in the two countries.
  52.  
  53. Without having actually worked out the framework of authority in the
  54. URN framework, there are no guidelines for how the implementation
  55. should either control or evolve authority on the participants. Are you
  56. presuming (as is presumed with MX records for mail, which I'm assuming
  57. is the model for NAPTR) that the operators of the resolution services
  58. for a single global name space are the same commercial entity?
  59.  
  60. The URN Framework document says only that 
  61.  
  62. > Some set of criteria must be established to govern what can and cannot
  63. > be used as a (top-level) namespace (NID assignment).  This can include:
  64.  
  65. >    . demonstration of an established namespace management system
  66. >      (including an overview of mechanisms for preventing the
  67. >      duplication/reassignation of name identifiers.  These mechanisms
  68. >      are particular to the individual namespaces).
  69. >    . multi-organization participation in the naming system
  70. >    . rules on how names are assigned, name assignment authority
  71. >      delegation
  72. >    . provision of escape clause 
  73.  
  74. but I think that any URN _resolution mechanism_ must be much more
  75. explicit to be credible: "multi-organization participation in the
  76. naming system" must deal with not just cooperation but contention.
  77. And it is absolutely imperative that any system of naming that is
  78. intended to be permanent (a prime URN requirements) must explicitly
  79. deal with the issue of how the _resolution mechanism_ deals with
  80. organizational change: not just the introduction of new organizations
  81. but also mergers and divestitures. (How do you deal with the split of
  82. AT&T and Bell Labs in the NAPTR records for tpc.urn.net?  What happens
  83. to duns.urn.net if Duns has a big argument with Bradstreet?)
  84.  
  85. > As far as I can see, all you get from their
  86. > scheme's _naming_ technique (as distinct from their security architecture)
  87. > that is different from a NAPTR style URN is the ability to refer to things
  88. > as relative to yourself.  This doesn't appear to be too useful as if you
  89. > distribute this name widely, people will either have to be given it in a
  90. > global form or be told where you are in the global scheme of things and
  91. > how your local namespace works.  You can't use somebody else's relative
  92. > names without either having their principle name in your local namespace
  93. > or just using their global name rooted at one of the special root names
  94. > (Rivest and Lampson explicitly point this out in the paper, "The
  95. > principal you call alice-smith may be different from the principal I call 
  96. > alice-smith.".  So putting just "alice-smith" in a the bibliography of
  97. > another document wouldn't be much use to anyone bar the creator). 
  98.  
  99. Well, no. If I'm going to write a bibliography for publication, I'll
  100. put in references that are relative to an authority that we mutually
  101. recognize. That's the whole point of putting 'publisher' in the
  102. references anyway: the publisher is the authority. ACM's Larry
  103. Masinter's article. The publication itself forms the context, and peer
  104. reviewers are expected to note references. Let's look at the
  105. references in draft-daniel-naptr-01.txt 
  106.  
  107. # [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen
  108. #     Sollins and Larry Masinter, Dec. 1994.
  109.  
  110. IETF's RFC's 1737
  111.  
  112. # [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
  113. #    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.
  114.  
  115. IETF's drafts' daigle-urn-framework-00
  116.  
  117. # [4] Paul Vixie, personal communication.
  118. #
  119.  
  120. author's Paul Vixie
  121.  
  122. with some assertion at the top that 
  123.  
  124. author = (LANL's Ron Daniel) + (Georgia Tech's Micahel Mealling)
  125.  
  126. How would _you_ write URNs for those references?  What are the
  127. authorities involved in assigning those references, and what would
  128. necessary for someone 50 years from now to be able to follow those
  129. references?
  130.  
  131. Larry
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.